1. Field of the Invention
The present invention relates generally to methods and apparatuses for transferring data to and from a first memory that is organized according to an object-oriented scheme to a second memory that is organized according to a relational database management scheme.
More specifically, the invention relates in certain embodiments to methods and apparatuses for transferring data to and from a transient storage that is organized according to an object-oriented scheme to a persistent storage that is organized according to a relational database management scheme. In certain embodiments, the relational database in persistent storage is designed by an object server. This includes defining the tables of the relational database as well as the various columns. The object server then stores and retrieves data from the various tables defined in persistent storage according to a hierarchical tree that maps data encapsulated within objects to table locations in the relational database found in persistent storage.
2. Description of the Related Art
There are well known tradeoffs associated with relational database and object oriented database designs. Relational databases are commonly optimized for fast, efficient searching. This is largely the result of the fact that relational databases are built from a set of tables that contain related columns. The tables are indexed in an efficient manner by the relational database so that searches may be performed in an optimal manner. While organizing information into a complex related set of tables helps speed searching, a thorough knowledge of the tables is required to specify data that is to be retrieved or to specify where data is to be stored. Furthermore, changing the structure of the tables to add a column may require extensive programming and rewriting of existing code. Another problem in many relational database management systems (RDBMSs) is that columns in tables that contain no information or are not used nevertheless take up space in memory.
A standard relational query language, Structured Query Language (SQL) is used to query most popular relational databases. SQL requires that the person who specifies a query know what tables and columns contain the information that is to be compared against the query. For example, in order to look for all customers in a city, the user must know both the name of the table that contains city information and also the name of the column in that table that contains the city information. It is also necessary that the user know the tables that should be joined to accomplish the search. Likewise, in order to store information in the proper column of the proper table, the user must know the name of the table and column in which the information should be stored.
In contrast, it is easier to query, modify and write information to object-oriented databases. Instead of specifying a table and column for storing or retrieving information, related data is encapsulated in an object. The object may be read into memory and all encapsulated data may be readily accessed. Searching, however, is not as efficient as relational database searching. Entire objects are read into memory in order to check the relevant encapsulated data members. Similarly, store operations are performed on entire objects. Thus, this methodology is not very well suited for on-line transaction processing (OLTP) where transaction rates are high but often only portions of the objects are desired.
Attempts to make object-oriented relational databases have for the most part merely added an object-oriented interpretation to a relational database structure. For example, rows in an existing relational database structure may be interpreted as an object, with each column representing an encapsulated data member. This arrangement, however, does not realize the full power of an object-oriented database. For example, inheritance is not supported so subclasses of objects may not be defined. Additionally, the problem of adding data members to objects is not addressed. Still further, adding a column with no data still allocates large chunk of storage for that column, even if the column is never used.
In view of the foregoing, there is a need for methods and apparatuses for taking advantage of the programming, storage and querying ease of an object-oriented database while enjoying the searching speed of a relational database.